|
|
|
|
|
|
|
subsystem, the electrical subsystem, and so on. Get the idea? The class, then, would be the atomic unit (assuming it did not contain other objects). |
|
|
|
|
|
|
|
|
Subsystems Talking to Each Other |
|
|
|
|
|
|
|
|
Subsystems (or categories) communicate with each other through classes that play the role of subsystem brokers/agents or subsystem interfaces. If you think of subsystems as themselves being big classes, a class within it would act as an agent on behalf of the subsystem. You might also view this agent class as a diplomat or an ambassador. When two subsystems need to communicate, one dispatches an ambassador's envoy (a message) to the other's ambassador. The hosting ambassador validates the message (making sure it's not a package bomb that might blow up and crash your system). If the ambassador feels the message has come to the right place, it will pass the message on to the proper authorities (some delegated class) for further processing. |
|
|
|
|
|
|
|
|
For instance, say a user of your application enters some personal information, such as name, address, and so on, and clicks a button to save the data to the database. At a high level, this is simple: Save it to the database straight from the form (or dialog box, for you C++ transplants). However, in OOP, the process is more method-based and organized. The form actually sends a message (packed with the data) to the GUI subsystem, which in turn separates the data from the form objects (that is, text box, list box, and so on) and sends it to a business layer class. This business layer class places each data value to its attributes (or properties), does some business rule processing, and if all is okay, sends this data to the database subsystem, which then saves this data to the database. (This process of saving class property values to the database is called persistence because the data persists beyond the current application session.) After you finish reading this book, you will be able to think your applications through in this manner (oops, didn't mean to scare you so soon). The idea of dividing an application into subsystems (or packages) is the core of object-oriented methods. |
|
|
|
|
|
|
|
|
Working with Design Models |
|
|
|
|
|
|
|
|
Quite naturally, when you plan the logic behind your object-oriented programming code, you'll need to properly model the relationships between objects. Design models provide pictures that represent an architectural overview of the application you're developing. You can create models and diagrams in Microsoft Visual Modeler, which I'll discuss on Day 3. |
|
|
|
|
|
|
|
|
A design model you'll work with is the class model. Class models show each class's structure as well as the relationships between classes. Microsoft published a popular |
|
|
|
|
|